An Approach to the Implementation of Overlapping 
Rules in Standard ML 



Riccardo Pucella 

Department of Computer Science 
Cornell University 
riccardo @ c s .cornel! . edu 



Abstract. We describe an approach to programming rule-based systems in Stan- 
dard ML, with a focus on so-called overlapping rules, that is rules that can still 
be active when other rules are fired. Such rules are useful when implementing 
rule-based reactive systems, and to that effect we show a simple implementation 
of Loyall's Active Behavior Trees, used to control goal-directed agents in the 
Oz virtual environment. We discuss an implementation of our framework using a 
reactive library geared towards implementing those kind of systems. 



1 Introduction 

Rule-based systems]] have had a long history in AI and powerful implementations have 
been developed. The most problematic aspect of this work has always been that of inte- 
grating the rule-based approach to a general-purpose language for application support. 
As an example along those lines, in [g], Crawford et al describe R++, a rule-based ex- 
tension to C++ completely integrated with the object-oriented features of the language, 
implemented as a rewrite of R++ into C++ code. 

One common use of rules, and indeed the primary motivation for this work, is to 
help write rule-based reactive systems, reactive in the sense of having the system react 
to changes in the environment. A change in the environment should enable a certain 
number of appropriate rules that can be fired to react to the environment change, possi- 
bly effecting new changes to the environment that will enable other rules. 

One aspect of rule-based reactive systems we focus on is that of long-acting over- 
lapping rules. In most rule-based systems, a single rule is active at any given time: when 
the system determines that a rule is enable, the rule is fired, the environment is updated, 
and a new rule can be selected. This is not so great is some of the rules are computation- 
ally intensive: when such a rule is fired, it will take time to execute and if the system 
relies on other rules to ensure say responsiveness of the interface, the system will not 
respond to the user until the rule has finished executing. In general one, may want rules 
that span multiple other rules firing. For example, one may pre-fire a rule when certain 
conditions are met, perhaps pre-computing some values, and get ready for the "real" 
firing once the "real" conditions are in place. Or one may want a rule that when fired 



1 In this paper, we focus exclusively on production rule systems. Related systems, such as those 
based on a notion of term rewrite rule, have not been considered at this point. 



will perform a given action at every subsequent rule firing until maybe a condition oc- 
curs that stops this behavior. It is of course possible to achieve these effects in certain 
rule-based systems, by a process of chaining rules (at the end of one rule, setting up 
the firing conditions of the next rule), along with a suitable notion of concurrently fired 
rules. 

In this paper, we describe an approach to the integration of rule-based programming 
in Standard ML (SML) [||], with a strong focus on overlapping rules to achieve the 
effects described above. The resulting framework is suitable for the design of domain- 
specific abstractions for various rule systems. In contrast with other work, we do not 
worry about efficiency issues in this paper, but rather concentrate on expressiveness 
and applicability of the framework. We assume throughout the paper a basic knowledge 
of SML, as described in various introductory material such as jio[p2| . 

After reviewing the basic notions of rule-based programming in Section ||, we dis- 
cuss the framework in Sections We give an application of the flexibility of the 
framework in Section |^, where we design domain-specific abstractions for controlling 
a goal-directed agent. Section |6| focuses on implementation details, including a refer- 
ence implementation in terms of an existing reactive library for programming reactive 
systems in SML, introduced in [njj, and based on the reactive approach of Boussinot 
Si- 



2 OPS -style production rules 

In this section, we establish the terminology and the model of rules we are interested in, 
namely OPS-style production rules [Eh. The production-system model of computation 
is a paradigm on the same footing as the procedural paradigm, the functional paradigm 
or the object-oriented paradigm: it is a view of what a computation ought to be to best 
achieve a given goal. 

A production-system program is an unordered collection of basic units of computa- 
tion called production rules (henceforth simply called rules). Each rule has a condition 
part and an action part. An inference engine is used to execute the rules: it determines 
which rules are enabled by checking which conditions are true, and select rules to ex- 
ecute ox fire from the enable rules. A rule is fired by executing its action part, which 
typically will have a side effect of performing input and output or computing a value 
and updating some date in memory. Thus rule-based systems fundamentally based on 
the notion of side effects. 

Many mechanisms can be used to select which enabled rule to fire. In the literature, 
the term conflict set is often used to name the set of rules which are enabled, reflecting 
the intuition that somehow these rules can be conflicting, that is update the store in 
different incompatible ways. To ensure such problems do not occur, production systems 
will typically select a single rule to fire, by methods involving various notions such as 
priority or probabilities, along with notions such as the best matching of the conditions 
and so on. 

In a rule-based system, control is data-driven, that is the data determines which part 
of the program will execute — furthermore, communication between different units is 
done solely through the use of data. There is no concept of a subroutine call to another 



rule, or anything of that sort. Rule-based systems allow a cleaner separation of knowl- 
edge (in the form of rules) from the control (encapsulated in the inference engine). This 
makes rule-based systems well-suited to program expert systems for analysis problems, 
and for programs for which the exact flow of control is not known. In this paper, we will 
make the further refined point that with the appropriate extensions, rule-based systems 
are well-suited for the compositional development of reactive systems. 

3 A framework for rule-based programming 

We begin by considering a general framework for the handling of simple OPS-style 
rules in SML, where actions are executed atomically and terminate before a new rule 
can be fired. We discuss the framework abstractly, that is in terms its interface. 

The first notion of importance is that of a set of rules, as an abstract type with a 
single basic operation that creates an empty set of rules. The reason for keeping the 
set of rules abstract is to allow for different implementations, some possibly aimed at 
optimizing the evaluation of the conditions. 

type rule_set 

val newSet : unit -> rule_set 

A rule is simply defined as a pair of a condition and an action, as in OPS. Since 
we want the condition to be dynamically evaluated, it is implemented as a function (the 
standard way to delay evaluation in an eager language such as SML). A condition eval- 
uates to a positive integer (a word), which we call the fitness of the condition, indicating 
the degree to which the condition is satisfied. There is no a priori semantics or range 
associated with those, they are left to the discretion of the programmer. The only re- 
striction is that a fitness of zero is used to indicate that a rule is not enabled. One can 
implement simple boolean conditions as values and 1, if need be. The only operation 
on rules is to add them to rule sets. Note that because functions are first-class in SML, 
rules become first-class as well. That is, they can be passed as argument to functions, 
and returned from functions. 

type rule = { cond : unit -> word, 

action : unit -> unit } 
val addRule : rule * rule_set -> rule_set 
val mkSet : rule list -> rule_set 

The final ingredient of the system is the inference engine, that selects which of 
the rules will be fired. At this point, the issue of when the rules should be fired must 
be addressed. Many systems tie the firing of the rules, or at least the evaluation of 
the conditions, to a change to variables that affect the conditions. We choose a much 
more fundamental approach using an explicit call that monitors the conditions, from 
which we can derive a change- of- state trigger. While inefficient, this approach has the 
advantage of being general. The other issue this does not address is that of conflict 
resolution, which rules to fire of all those that are enabled. We provide a selection of 
conflict resolution strategies. A function monitor is used to select rules to fire in a given 
set of rules. It takes as argument a conflict resolution flag determining the resolution 
strategy to use: 



datatype conflict_res = AllBest 
RandBest 

AllDownTo of word 
RandDownTo of word 
val monitor : conf lict_res -> rule_set -> unit 

AllBest fires all the rules that qualify as the best rule to apply, sorted according to fit- 
ness. RandBest randomly picks one of the rules that qualify as the best rule. AllDownTo 
and RandDownTo perform similarly, but consider all the rules whose fitness is at least 
the given value. One can easily extend the framework to allow for custom conflict res- 
olution, which we do not pursue in this paper for simplicity. 

Our notion of fitness is general. As we noted, we can imagine a binary fitness (0- 
1) for boolean firing, but also a fitness based on how close the conditions are to being 
completely satisfied, or even so far as how many conditions are actually satisfied (if we 
allow firing based on partially satisfied conditions). An easy extension to the framework 
would be to pass information from the condition to the action. We can mimic this easily 
by using a reference cell which can also be hidden in a closure of the rule, as follows: 

let 

val r - ref 

in 

{cond = compute fitness, store something in r, 
action - some action using the value in r] 

end 

In striking difference with other systems, rules are not persistent in this framework: 
once a rule fires and executes, it is removed from the rule set. To make a rule persis- 
tent, we can use the function persistent. This allows us to dispense with a function to 
remove rules from rule sets. Moreover, persistent comes for free given our extension 
for managing overlapping rules, as we will see in the next section. 

val persistent : rule -> rule 

As an example of how to use the framework, consider a simple rule-based program 
to compute the greatest common divisor of two integers, the classic Euclid's algorithm. 
The example is artificial (it is easily implemented in SML without rules), but serves 
well to illustrate the basics. A more complete example is presented in Section ^. The 
program can be expressed as follows in Dijkstra's language of guarded commands: 

doX >Y -> X := X -Y \Y > X ->• Y := Y - X od 

The corresponding code in our framework is more verbose, but essentially similar: 

fun god (x,y) = let 
val rx - ref x 
val ry - ref y 

fun r (rl,r2) - persistent 

{cond = fn () => if (!rl) > (!r2) 
then 1 else 0, 
action = fn {) => rl := (!rl) - (!r2)} 
val rs - mkSet [r (rx, ry) , r (ry,rx)] 
fun loop () = if ((!rx) - (!ry)) then (!rx) 

else (monitor AllBest rs; loop ()) 

in 

loop 
end 



The above example is interesting because it shows how the fact that rules are first- 
class in the framework allow for parametrized rules: the rule r in the above code is 
parametrized over the reference cells containing the two arguments, parameterization 
which nicely showcases the symmetry of the rules. 

As a final remark, we note that the rules as we have presented them in this sec- 
tion are simpler than they are in the actual framework. The rules in the implemented 
framework contain an extra field generically called data whose type is a parameter to 
the structure implementing the rules (in effect, the library is implemented as a functor). 
The monitoring function takes as an extra argument a function to compute a fitness both 
from the result of the evaluation of the condition and the data (which for example can 
contain notions such as rule priority and so on). Since describing this explicitly would 
require us to go into the details of both the module system and the type system of SML, 
we punt on these issues in this paper. 

4 Managing overlapping rules 

The main point of this work was to introduce overlapping rules, that is rules that can 
span multiple invocations and be performed in parallel with other rules. From an inter- 
face point of view, the framework only requires the addition of a single primitive, which 
we call wait, to add the desired functionality: 

val wait : (unit -> word) optionjj -> unit 

The semantics of wait is simple. Fundamentally, wait interrupts the action of the 
current rule, as if the rule was finished executing, except that at the next time the mon- 
itoring function is invoked to fire a rule, the rules that were interrupted are allowed to 
resume while the new rule fires. Hence the term overlapping. In fact, the wait primi- 
tive takes two forms. The form wait (NONE) behaves as an unconditional interruption. 
Execution continues the next time the monitoring function is invoked. The form wait 
(SOME (f)) with / as a condition (that is, a unit — > word function) also interrupts, but 
only resumes the rule the next time the monitoring function is invoked with the con- 
dition/ being satisfied. In effect, wait (SOME (f)) interrupts the rule and conceptually 
replaces it with a new rule containing the remainder of the interrupted rule, with a con- 
dition/ 

As we mentioned in the previous section, rules are not persistent: once they are 
fired and execute, they are removed from the rule set. We can implement the persistent 
function using wait: 

fun persistent { cond, action } = 
{cond - cond, 
action = let 

fun loop = (action (); 

wait (SOME (cond) ) ; 
loop ()) 

in 

loop 
end} 



This nicely shows the power of first-class rules. 

2 a primitive SML type defined as datatype 'a option = none i some of 'a. 



5 An application: goal-directed agent control 



We describe in this section one of the motivating applications for the development of the 
framework in the first place, that of controlling goal-directed agents. The architecture 
we have in mind is inspired by Hap, a reactive, goal-driven architecture for controlling 
agents in the Oz virtual environment [|]| . The main structure in Hap is an active behavior 
tree (ABT), which represents all the goals and behaviors an agent is pursuing at any 
given point [Q]. An agent chooses the next step to perform by selecting one of the 
leaves of its ABT. Three types of actions can be performed depending on the type of 
the node selected. 

1. Primitive physical action: an action sent to the action server, which can either 
succeed or fail depending on the state of the world. 

2. Primitive mental action: an action that simply performs a computation (possibly 
with side effects) and which always succeeds. 

3. Subgoal: an action corresponding to a new subgoal; an appropriate behavior is 
selected that matches that subgoal, and the ABT is expanded by adding the steps 
specified by the behavior to the tree as children of the subgoal selected. 

(For our purposes, we drop the distinction between mental and physical actions, 
since we can model mental actions as physical actions that always succeed). Program- 
ming an agent reduces to programming behaviors for various goals. Goals have no 
intrinsic meaning, they are simply names on top of which the programmer can attach 
any semantics she desires. Behaviors are defined by specifying to which goal they ap- 
ply, a pre-condition for the application of that behavior (simply a predicate over the 
state of the world), and the steps that the behavior prescribes (physical actions, mental 
actions, subgoals). At this point, many details enter the description, to provide control 
over managing goals and behaviors. There are three kind of behaviors: 

1 . Sequential: the steps are performed in order, and failure of any step signifies the 
failure of the corresponding goal to which the behavior is attached; success of the 
last step signifies success of the corresponding goal. 

2. Concurrent: the steps are performed in any order, but again failure of any step 
signifies the failure of the corresponding goal. 

3. Collection: the steps are performed in any order, but success or failure of the steps 
are irrelevant. When all steps have succeeded or failed, the corresponding goal 
succeeds. 

Subgoals steps in behaviors can moreover be annotated as persistent, that is when they 
succeed or fail, they are not removed, but rather persist as a continuing goal. Typically, 
top-level goals are persistent. Conversely, subgoals can be annotated with a success 
test, a predicate over the state of the world, which gets tested every time the ABT is 
activated. If the success test of a subgoal is true, the subgoal automatically succeeds. 

Choosing a step to perform is by default done at random over all the applicable 
steps in an ABT, that is all the leaves that can be either executed right away or subgoals 
that can be expanded because a behavior applies (no behavior may apply because either 
none has been defined or no pre-condition is satisfied). Similarly, choosing a behavior 



to perform once a subgoal step has been chosen is by default done at random over all 
applicable behaviors. One can modify this default by assigning priorities to various 
subgoals. 

All of this is meant to evoke the kind of structure we would like to express in our 
framework. Since Hap revolves around the notion of goals, we abstractly provide a 
notion of goal to the framework of the previous sections, where goals are for simplicity 
represented as strings. 

datatype goal_status = Success I Failure 
Active I Available 
NoSuch 

val goalSet : string -> unit 

val goalSucceed : string -> unit 

val goalFail : string -> unit 

val goalStatus : string -> goal_status 

val goalClear : string -> unit 

where goalSet enables the given goal, such that it is to be pursued by the agent (it 
becomes available). The functions goalSucceed and goalFail are used to record that a 
goal has succeeded or failed. The function goalStatus returns the status of the given 
goal. The status of a goal is either Success or Failure if the goal has been recorded 
as such, or Active if a behavior is actively pursuing the goal, but is not done with it 
yet. A status of Available indicates that the goal is enabled, but that no behavior is 
pursuing it, while a status of NoSuch indicates that no such goal exists. The function 
goalClear removes a goal from the active list of goals. We define the boolean-valued 
helper functions isAvailable and isDone to check the status of a goal to be respectively 
Available or Success/Failure. 

We interpret an ABT behavior as a rule, triggered both by the pre-condition of 
the behavior (if present) and the apparition as Available of the goal the behavior is 
meant to pursue. We do not worry about either sequential, collection or concurrent 
annotations, choosing rather to let the programmer manage the steps of the behavior 
explicitly. Patterns quickly emerge. For instance, a behavior for goal g triggered by a 
condition c and sequentially performing subgoal gl, action a and subgoal g2 can be 
interpreted as a rule: 

val behl = 

{ cond - fn () -> if isAvailable (g) andalso c 
then 1 else 0, 

action = fn () => 

(goalSet (gl) ; 

wait (SOME (fn () => isDone (gl)))} 
case (goalStatus (gl) ) 

of Success => (goalClear (gl) ; 
a; 

wait (NONE) ; 
goalSet (g2) ; 

wait (SOME (fn () => isDone (g2) )) ; 
case (goalStatus (g2) ) 

of Success => (goalClear (g2) ; 

goalSucceed (g) } 
=> (goalClear (g2) ; 
goalFail (g) ) ) 

_ => (goalClear (gl) ; 

goalFail (g) ) ) ( 

Similarly, the previous behavior can be implemented concurrently by setting all the 
goals at once and waiting for all the goals to be done. 



val beh2 = 

{ cond - fn () -> if isAvailable (g) andalso c 
then 1 else 0, 

action = fn () => 

(goalSet (gl) ; 
goalSet (g2); 
a; 

wait { SOME (fn () => isDone (gl) andalso isDone (g2) ) ) ; 
case (goaistatus ( gl } , goalStatus {g2) ) 
of (Success, Success) => (goalClear igl)} 
goalClear {g2) ; 
goalSucceed (g) } 
(_,_) => (goalClear igl); 

goalClear (g2) ; 
goalFail (g) ) ) } 

By virtue of the andalso in the first waiting condition of beh2, the conditions must 
all be true for the system to proceed at that point. Although it does sequentializes the 
testing of the conditions, this is not an issue given our current framework since the rule 
is resumed when all the conditions are satisfied. It may however become an issue if 
we attempt to optimize the satisfaction of the conditions. Persistence of goals can be 
implemented by clearing them and setting them again, while goal success tests can be 
wrapped inside the wait condition for that goal. 

One difficulty of this approach, immediately noticeable from the above code, is that 
it is very error-prone, even if it is much more flexible than ABTs. In effect, we have to 
implement the handling of the goals explicitly, for every single behavior. However, the 
flexibility of first-class rules and first-class functions allows us to easily generate such 
rules from a declarative description of the intended behavior. Consider a type behavior 
that describes a behavior declaratively: 

type behavior - {goal : string, 

precond : (unit -> bool) option, 

kind : behavior_kind, 

steps : behavior_step list} 
datatype behavior_kind = Sequential I Concurrent 
datatype behavior_step - Subgoal of string 

Action of unit -> bool 

(For simplicity, we drop the collective kind of behavior, its handling similar enough to 
the concurrent one to not cause a problem). We can describe the previous two behaviors 
behl and beh2 as follow (this time using behavior parameterization!): 

fun beh (k) = {goal = g, 

precond = SOME (fn () => c) , 
kind - k, 

steps = [Subgoal (gl), 

Action (fn ( ) => a) , 

Subgoal (g2) ] } 
val behl - beh (Sequential) 
val beh2 - beh (Concurrent) 

We can then interpret such descriptions in our framework, by a function behavior- 
Rule, which takes a description of type behavior and returns a rule of type rule. The 
implementation of behaviorRule is simply a question of writing a rule whose action is 
an interpreter for lists of behavior .step. For the truly interested, the code for behavior- 
Rule is given in Figure |l| 



fun behaviorRule { goal, precond, kind, steps } = let 
fun split [] = <[],[]) 
I split (x : : xs) = let 

val (sg, acts) = split (xs) 

in 

case x 

of Subgoal (g) => (g::sg,acts) 
I Action (a) => (sg,a::acts) 

end 

fun cond () = if isAvailable (goal) andalso 

(case precond of NONE => true 

| SOME (pc) => pC () ) 
then 1 else 

in 

case kind 

of Sequential => let 

fun perf orm_steps [] = goalSucceed (goal} 
I perf orm_steps (Action (a)::r) = 
(a (); 

wait (NONE} ; 
perf orm_steps (r) } 
I perf orm_steps (Subgoal (g) : :r} = 
(goalSet (g) ; 

wait (SOME (fn () => isDone (g) } ) ; 
case (goalStatus (g) } 

of Success => (goalClear (g) ; 

perf orm_steps (r) ) 
| _ => (goalClear (g) ; 

goalFail (goal) ) ) 

in 

{cond = cond, 
action = fn (} => perf orm_steps (steps)} 

end 

I Concurrent => 
{cond = cond, 
action = fn (} => let 

val (subgoals, actions) = split (steps} 

in 

app goalSet subgoals; 

app (fn a => a ()) actions; 

wait (SOME (fn () => List. all (fn x => x) 

(map isDone subgoals)}); 
if (List. all (fn g => case (goalStatus (g) } 
of Success => true 
I _ => false} 

subgoals } 
then (app goalClear subgoals; 
goalSucceed (goal) } 
else (app goalClear subgoals; 
goalFail (goal) } 

end} 



Fig. 1. Code for behaviorRule 



6 Implementation 



The framework we have described has been implemented for the Standard ML of New 
Jersey compiler ^ using the reactive library described in jTT|], One advantage of this 
approach is that the semantics of the system is easily derivable from the one in [pi]]. 
Before discussing the implementation, let us give an overview of the reactive library. 

The library defines a type rexp of reactive expressions, which are expressions that 
define control points. A reactive expression is created through a function rexp that ex- 
pects a unit — + unit function as argument. The argument function calls the function stop 
to define a control point. The function react is used to take a reactive expression and to 
evaluate the code starting from the last control point reached until the next control point 
is reached. This is called activating a reactive expression. When a reactive expressions 
evaluates to a value without reaching a control point, it is said to terminate. Interest- 
ing combinators can be defined to take reactive expressions and combining them. The 
most important of such combinators is the merge combinator, which takes two reactive 
expression e% and e-i and creates a new reactive expression e that behaves as follows: 
when e is activated, e\ and €2 are activated, one after the other. In effect, this inter- 
leaves the execution of e\ and e%. The combinator loop takes a reactive expressions e\ 
and creates a new reactive expression e that behaves as follows: when e is activated, e\ 
is activated. If e\ terminates, it is reset (the reactive expression is re-instanciated) and 
activated again. The reactive expression nothing simply terminates immediately. 

A more fine-grained notion of control point is also available. A reactive expression 
can call suspend to suspend its current execution. A suspend acts as a stop, except that 
a special combinator close is available. Given a reactive expression ex, close returns a 
new reactive expression which behaves as follows: when e is activated, it repeatedly ac- 
tivates ei until all its reactive subexpressions have reached stop-defined control points. 
This allows finer control over the order of execution of the reactive subexpressions, an 
example of which we will see in this section. 

It is clear, given this description, how the library may be useful to implement the 
details of overlapping rules. For brevity, we assume the reactive library has been bound 
to a structure R. The implementation of the framework is rather simple, although it 
is complicated by technical details and some mismatches with the underlying reactive 
library. We define a rule set as a reactive expression, a merge of all the relevant rules. 

type rule_set - R.rexp 
fun newSet () - R. nothing 

A rule is defined as before, while adding a rule to a set of rules consists of merging 
the reactive expression corresponding to the rule in the merge of the rule set. 

type rule = { cond : unit -> word, 

action : unit -> unit} 
fun addRule rs { cond, action } = let 

val r = R.exp (fn () => (condition (cond); 

action ( ) ) ) 

in 

R. merge (rs, r) 
end 

val mkSet = foldr addRule (newSet ()) 

The function condition terminates immediately if monitoring determines that it 
should be fired (according to the fitness of the condition), otherwise it stops to wait 



for another instant where the condition is deemed fit. To bypass a limitation of the cur- 
rent reactive library, which is more geared towards locally determining whether a given 
reactive expression is allowed to continue rather than being selected through a global 
check, we introduce a global variable to hold a list of all computed fitnesses and allow 
the system to select the ones that will execute []. 

val globalFitnesses = ref ([]} : (unit ref * word) list ref 

We uniquely tag each condition being computed using a value of type unit ref, a 
trick commonly used in SML to get unique identifiers that can be quickly compared for 
identity. When the function condition is encountered, the current fitness is computed and 
stored along with a unique identifier for the condition. The reactive expression is then 
suspended (not stopped). This gives the other reactive expressions running in parallel a 
chance to evaluate their conditions. Upon resumption of the suspension, each condition 
checks if it is allowed to continue by seeing if it is listed in a list of allowed-to-continue 
conditions, stored in the previous globalFitnesses variable. 

fun condition (f) = let 
val r - ref () 

fun loop = (globalFitnesses := (r, f) ::(! globalFitnesses ) 
suspend ( ) ; 

if (List. exists (fn (r',_) => r-r' ) (! globalFitnesses) ) 

then ( ) 
else (stop 0; loop ())) 

in 

loop 
end 

The function wait that implements an interruption of the execution of the rule is 
simple: 

fun wait (NONE) = (stop (); suspend 0) 

wait (SOME (f)) = (stop (); condition (f)) 

(The suspend in wait (NONE) is a technicality, needed to prevent the firing of stopped 
rules with no conditions until all the conditions of the other rules have been checked). 

The core of the work is done in monitor, which is in charge of activating the reactive 
expression corresponding to the rule set, gather the results, compute which conditions 
are satisfied, and resume the suspensions. 

fun monitor c rs - let 

val clearVar - R.loop (R.rexp (fn () => (globalFitnesses :- [ ] ; 

stop ()))) 

val r - R.loop (R.rexp (fn () => { computeEnabled (c); 

stop ()))) 

in 

R. react (R. close (R. merge ( clearVar, R . merge (rs,r)))} 
end 

The above code encompasses the control flow of the monitoring process, and relies 
heavily on the fact that merges are deterministic. A non-deterministic implementation 
could play with suspend calls to achieve the right order of execution: we need to make 
sure at every instant that clearVar is executed first, and computeEnabled is activated 
after all suspensions. The actual rule selection is performed by computeEnabled: 

This does make the library non-reentrant. This could be corrected by an appropriate change to 
the reactive library (implementing reaction-specific data, for instance), or by including a notion 
of execution context to bind the use of the variable to a given context. 



fun computeEnabled (AllBest ) = let 
fun max (curr, []) = curr 

I max (curr, (_,x)::xs) = if x>curr then max (x,xs) else max (curr,xs) 
val bestVal = max (1, ! globalFitnesses ) 

val 1st = List. filter (fn (_,a) => a=bestVal) (! globalFitnesses) 

in 

globalFitnesses := 1st 
end 

I computeEnabled (RandBest ) = (as AllBest , but return random element ) 
I computeEnabled (AllDownTo (v) ) = let 

val 1st - List. filter (fn (_,a) => (a>=v) ) (! globalFitnesses ) 

in 

globalFitnesses : = 1st 
end 

| computeEnable (RandDownTo (v) ) = (as AllDownTo, but return random element ) 



7 Conclusion 

So what have we done? We have developed a general framework for rule-based pro- 
gramming in SML, flexible enough to handle standard OPS-style rules, as well as over- 
lapping rules. The fact that rules are first-class in the framework gave us enough flex- 
ibility to express Loyall's active behavior trees through an interpreter of declarative 
behaviors. 

We have not worried about the efficiency of the framework. Some rather standard 
optimizations as found in modern rule-based systems can easily be applied, although 
optimizations of the conditions may require them to be lifted into a more structured 
type, such as for example 

datatype condition = Basic of unit -> word 
And of condition list 
Or of condition list 
I Not of condition 

in order to allow for such things as caching of condition evaluations and so on. On 
another note, evaluating a condition is only required if the references the condition 
refers to have been changed, so an optimized framework should maintain a list of the 
references used by conditions and record changes accordingly. 

The tradeoff between generality and conciseness is not new. If we are willing to 
restrict flexibility, we can design an appropriate surface language which we can trans- 
late into this framework for execution. This is what we did for the implementation of 
behaviors in Section |[ This makes our framework a target language for the interpreta- 
tion of domain-specific rule-based languages. In a similar way, the reactive library of 
jTT| ] was designed as a target language for the interpretation of domain-specific reactive 
languages, which is the way it is being used in this paper. 

Using the SugarCubes framework described in [Q], we could move most of the 
framework to Java, but SML has distinct advantages, at least at first brush: we have seen 
how first-class rules and first-class functions helped design suitable domain-specific ab- 
stractions; the module system, although not used in this paper, plays a crucial role in 
the generalization of the framework to general rules that can carry arbitrary data (not 
only conditions and actions). The whole approach is also helped by the fact that SML 



already implements state-based programming through the use of explicit references. It 
will be interesting to see how much of this can be carried over to Java. 

This frameworks, one of the first implemented using the library in Jll[], also points 
to some conclusions about the reactive approach. If the order in which parallel reactive 
expressions are activated is important, then we need to be careful, appropriately using 
suspend calls to get the order right; this makes the resulting system brittle and the code 
hard to see correct. A better approach may be to allow one to explicitly control the 
order of execution of the branches of a merge. On a related note, the reactive library 
is geared towards determining reactive expression activation locally, while we have 
encountered in this paper a reasonable instance where the activation decision is taken 
on a global level. It would be interesting to find an extension of the reactive library to do 
that cleanly, without resorting to a list of unique identifiers indicating which expression 
is allowed to resume. 
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